[% setvar title The Perl 6 Summary for the fortnight ending 2005-11-13 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the fortnight ending 2005-11-13'></a><h1>The Perl 6 Summary for the fortnight ending 2005-11-13</h1>
<p>Welcome to another fortnight's worth of summary. We'll get back to a weekly
schedule one of these fine days, you see if we don't.</p>
<a name='This fortnight in perl6-compiler'></a><h1>This fortnight in perl6-compiler</h1>
<p>There was a surprisingly large amount of activity on the list, but again, the
place to look for perl6 compiler news is the Planet Perl Six aggregator.</p>
<p><a href='http://planetsix.perl.org/' target='_blank'>planetsix.perl.org</a></p>
<a name='PGE improvements and changes'></a><h2>PGE improvements and changes</h2>
<p>Patrick announced that he'd checked in some major changes to the PGE
internals. The changes include a shiny new shift-reduce operator precedence
parser which is used to parse the rules themselves. PGE finally has a
<code>&lt;p6rule&gt;</code> parsing rule which can be used to parse a valid Perl 6
rule. There are other changes, but those two are the headlines. Patrick asked
for the usual questions, comments, patches and tests.</p>
<p>A couple of days later, he posted a more comprehensive overview of the new and
shiny bits in PGE.</p>
<p><a href='http://groups.google.com/groups?threadm=20051101062541.GA30198@host.pmichaud.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=20051104144923.GA12353@host.pmichaud.com' target='_blank'>groups.google.com</a></p>
<a name='PGE problem with non-greedy quantifiers'></a><h2>PGE problem with non-greedy quantifiers</h2>
<p>Allison fell foul of some changes in the new PGE. This turned out to be a bug
in PGE, so Patrick fixed it.</p>
<p><a href='http://groups.google.com/groups?threadm=ED559257-B0D9-4216-98E4-88C0AC3B4F0F@perl.org' target='_blank'>groups.google.com</a></p>
<a name='The meaning of \n and \N'></a><h2>The meaning of \n and \N</h2>
<p>Noting that Synopsis 5 says that '<code>\n</code> now matches a logical (platform
independent) newline, not just <code>\012</code>', Patrick asked the list for more
details about what that should mean so he could get on and implement it in
PGE. He offered up a suggested matching rule. Larry thought that the suggested
rule was close enough for jazz.</p>
<p><a href='http://groups.google.com/groups?threadm=20051104155307.GA15393@host.pmichaud.com' target='_blank'>groups.google.com</a></p>
<a name='[] and () on rule modifiers'></a><h2><code>[]</code> and <code>()</code> on rule modifiers</h2>
<p>Patrick continues to work on the PGE. This time he asked about the behaviour of
rule modifiers, with particular reference to the <code>:w</code> modifier. Larry had
answers.</p>
<p><a href='http://groups.google.com/groups?threadm=20051104192614.GA30432@host.pmichaud.com' target='_blank'>groups.google.com</a></p>
<a name='Parrot 0.3.1 &quot;Wart&quot; released'></a><h2>Parrot 0.3.1 &quot;Wart&quot; released</h2>
<p>Leo announced the release of Parrot 0.3.1 &quot;Wart&quot;, complete with shiny new
features like variable sized register frames and no more spilling, a much
better PGE (see above) and other goodies. The latest release has more than 3000
tests, and that's probably still not enough.</p>
<p><a href='http://groups.google.com/groups?threadm=436E0DBB.8040300@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Octal in p6rules (and strings)'></a><h2>Octal in p6rules (and strings)</h2>
<p>Patrick Continued his voyage of stringy discovery, this time asking about the
black art of specifying glyphs/bytes/whatever using octal notation. He wondered
about his assumption that the correct way to do it is with <code>\o123</code> by analogy
with using <code>0o123</code> to specify a number in octal. He also wanted confirmation
that the <code>\nnn</code> notation had been dropped. A surprisingly long discussion
ensued as Larry did a good deal of thinking aloud and Patrick got on with
implementing the nailed down bits.</p>
<p><a href='http://groups.google.com/groups?threadm=20051107165159.GA13344@host.pmichaud.com' target='_blank'>groups.google.com</a></p>
<a name='Meanwhile, in perl6-internals'></a><h1>Meanwhile, in perl6-internals</h1>
<a name='SWIGging Parrot'></a><h2>SWIGging Parrot</h2>
<p>John Lenz is one of the developers a SWIG, which started off as the Python
equivalent to Perl's XS. He had some questions about writing a SWIG module for
parrot and asked if there would be interest in having SWIG be one of the
'official' ways of doing native calls from Parrot. Leo thought not, pointing
out that Parrot's NCI is fully dynamic and groovy.</p>
<p><a href='http://groups.google.com/groups?threadm=35051.192.168.0.12.1130741345.squirrel@192.168.0.2' target='_blank'>groups.google.com</a></p>
<a name='NCI using ffcall library'></a><h2>NCI using ffcall library</h2>
<p>Garrett Goebel joined in the ongoing discussion of using ffcall to implement
the Parrot NCI (Native Call Interface) by pointing back to an earlier
discussion of using libffi to implement the Parrot NCI. Last time round, Dan
had pointed out that, because libffi is an external library, there still needs
to be a supported (if possibly hackish) way of doing NCI that comes with
Parrot, but that configure could probe for external libraries to use where they
are available.</p>
<p><a href='http://groups.google.com/groups?threadm=E4901162278E99499731C168EC803B59991554@mail.scriptpro.com' target='_blank'>groups.google.com</a></p>
<a name='Heredocs in function calls'></a><h2>Heredocs in function calls</h2>
<p>Patrick wondered if there might be a convenient way to support heredoc
parameters in PIR function calls. Nicholas Clark wondered why one would bother
since most PIR code should be generated code.</p>
<p>Later on, Leo implemented them. About the only place they don't work now is in
macro arguments.</p>
<p><a href='http://groups.google.com/groups?threadm=20051101074509.GA1506@host.pmichaud.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=4369CBC7.1070407@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Simple register allocation'></a><h2>Simple register allocation</h2>
<p>Summarizing a discussion on IRC, Patrick noted that it would be nice if the PIR
compiler had a way to use a very basic register allocation for .subs that only
use a small number of registers. After all, there's little point in doing a
complex analysis of control flow if a sub uses (say) 5 registers at most. The
problem is that this analysis gets harder as the subs get longer (O(n) on the
length of the sub). In the case of PGE (for instance), the subs can get very
long, with lots of control flow statements, but use a maximum of 10 PMC, 9 int
and 4 string registers for the whole thing.</p>
<p>Warnock applies.</p>
<p><a href='http://groups.google.com/groups?threadm=rt-3.0.11-37578-123722.7.0478443353673@perl.org' target='_blank'>groups.google.com</a></p>
<a name='Careful with that bsr Eugene'></a><h2>Careful with that <code>bsr</code> Eugene</h2>
<p>Leo noted that, with the introduction of variable sized register frames, it is
no longer legal to <code>bsr</code> into a different <code>.sub</code>.</p>
<p><a href='http://groups.google.com/groups?threadm=ce791f585f2d5b3ae727692fa6476666@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Reconfiguring configure'></a><h2>Reconfiguring configure</h2>
<p>Joshua Hoblitt sketched out a route map for getting from our current 'built to
throw away' configuration system to the sunny uplands of the miniparrot based
config system. Everyone who commented sounded positive. Now, if someone could
just implement it...</p>
<p><a href='http://groups.google.com/groups?threadm=20051103073105.GB16634@ifa.hawaii.edu' target='_blank'>groups.google.com</a></p>
<a name='Shifting right by more than the width of int'></a><h2>Shifting right by more than the width of int</h2>
<p>Joshua Isam had problems doing a right shift of more than the width of an
integer. Which is no surprise really as the behaviour is officially undefined
in the C spec, which is the implementation that Parrot uses. There was some
discussion, but the consensus is that it's best to stick with the C semantics
for integer registers and if the need arises for more complex semantics, it's
always possible to write a new PMC.</p>
<p><a href='http://groups.google.com/groups?threadm=740b6a05281f1e3f3b54cd7791838a51@ritalin.shout.net' target='_blank'>groups.google.com</a></p>
<a name='Suspend and resume opcode'></a><h2>Suspend and resume opcode</h2>
<p>Tomo sent in a patch implementing <code>suspend</code> and <code>resume</code> opcodes. After a
certain amount of kerfuffle involving the mailing list software stripping troff
attachments and dodgy software deciding that a .t file full of tests was
actually a troff source, Leo rejected the patch and pointed Tomo in the
direction of coroutines.</p>
<p>The mailing list will now accept troff attachments. Hurrah.</p>
<p><a href='http://groups.google.com/groups?threadm=436B403C.2000307@nekomimists.ddo.jp' target='_blank'>groups.google.com</a></p>
<a name='Creeping up on ffcall NCI'></a><h2>Creeping up on ffcall NCI</h2>
<p>Nick Glencross posted another update of his work on getting NCI to use the
ffcall library. He's now added config smarts to detect the ffcall and other
handy features.</p>
<p><a href='http://groups.google.com/groups?threadm=dcb629180511040927kd7042f2vdb722f49a4df2a9a@mail.gmail.com' target='_blank'>groups.google.com</a></p>
<a name='Removing unmaintained languages from parrot tree'></a><h2>Removing unmaintained languages from parrot tree</h2>
<p>Jerry Gay noticed that there were an awful lot of unmaintained languages in the
Parrot tree. He recommended getting in touch with their last known authors and
eventually removing the dead languages.</p>
<p><a href='http://groups.google.com/groups?threadm=rt-3.0.11-37611-123890.17.8232124086628@perl.org' target='_blank'>groups.google.com</a></p>
<a name='Testing non-core PIR libraries with Parrot::Test'></a><h2>Testing non-core PIR libraries with Parrot::Test</h2>
<p>Allison outlined some of the problems she'd been having testing her tree
transformation engines outside of the parrot tree. It turns out that Parrot or
the Test tool require absolute paths to various libraries, which is no fun at
all. She suggested fixing Parrot::Test up so as to try and divine (and set) a
sensible load path for Parrot. Meanwhile, chromatic continues to beaver away at
implementing Test::More in PIR.</p>
<p><a href='http://groups.google.com/groups?threadm=D3C8F121-06ED-40BF-B5E4-DB94D0414B12@perl.org' target='_blank'>groups.google.com</a></p>
<a name='Updating parrotcode.org'></a><h2>Updating parrotcode.org</h2>
<p>Will Coleda announced that he'd been doing some tidying up of the
parrotcode.org website and asked for suggestions for an updated 'where we are'
section. Various answers and suggestions were provided.</p>
<p><a href='http://www.parrotcode.org/' target='_blank'>www.parrotcode.org</a></p>
<a name='find_type considered dubious'></a><h2><code>find_type</code> considered dubious</h2>
<p>Roger Browne was puzzled by the behaviour of the <code>find_type</code> opcode, which
works for both PMC types and native Parrot types. He thought that this was both
confusing and counter productive. Leo didn't seem to agree with him.</p>
<p><a href='http://groups.google.com/groups?threadm=1131544548.7662.9.camel@eiffel.demon.co.uk' target='_blank'>groups.google.com</a></p>
<a name='Unicode strings and encodings'></a><h2>Unicode strings and encodings</h2>
<p>Leo announced that he's going through the various string functions to make them
usable with all the string encodings we know about. He outlined what he
proposed to do solicited comments in case of insanity.</p>
<p><a href='http://groups.google.com/groups?threadm=437353FF.5020106@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Legal names for PMCS'></a><h2>Legal names for PMCS</h2>
<p>Roger Browne (whose name I keep wanting to use as a Clerihew) wondered what the
rules were for naming PMCs. Leo reckoned that, unless someone rejigs
<b><i>pmc2c.pl</i></b> to mangle non word characters appropriately, a PMC name should
follow the same rules as C identifiers.</p>
<p><a href='http://groups.google.com/groups?threadm=1131707019.23357.6.camel@eiffel.demon.co.uk' target='_blank'>groups.google.com</a></p>
<a name='string_bitwise_*'></a><h2><code>string_bitwise_*</code></h2>
<p>Noting that, with ICU installed, parrot has 'rather complete support for
Unicode string manipulation', Leo wondered about making the bitwise string
manipulations work. In particularly, he wondered how they should behave in the
face of charset and/or encoding mismatches. According to Leo, it seems to boil
down to a choice between throwing an exception or simply mashing everything
together and marking the 'resulting bit mess' as binary. Warnock applies.</p>
<p><a href='http://groups.google.com/groups?threadm=4375E49D.5060405@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Parrot fink'></a><h2>Parrot fink</h2>
<p>Will Coleda passed on a query from the #parrot irc channel. Someone had
wondered if there was a Fink build of Parrot available. (Fink is an OS X open
source package manager along the lines of, well, pretty much every other
package manager). There isn't, so Will wondered if there was anyone on the list
who could help put one together. Leo noted that Parrot is already Debianized
(yay!) which might help with the fink approach too. Joshua Isam worked on the
task.</p>
<p><a href='http://groups.google.com/groups?threadm=AD8403CA-D106-414E-8D85-DE525AEA37BD@coleda.com' target='_blank'>groups.google.com</a></p>
<a name='Changing default STDOUT/STDERR Filehandles for PIR code'></a><h2>Changing default STDOUT/STDERR Filehandles for PIR code</h2>
<p>One of the things that chromatic needs in order to write a pure PIR version of
Parrot::Test is a way to redirect STDOUT and STDERR within a section of PIR
code. He's looked at the implementation of the ParrotIO PMC and the print
opcode, but can't see where to begin. So, he asked for help. At close of play
on Sunday there had been no answer, but I'm sure someone will be along soon.</p>
<p><a href='http://groups.google.com/groups?threadm=1131833503.24170.5.camel@localhost' target='_blank'>groups.google.com</a></p>
<a name='PDD20: An idea: Call frames as PMCs'></a><h2>PDD20: An idea: Call frames as PMCs</h2>
<p>Chip led the applause for Leo's implementation of the new lexical scheme in all
of a week. He then went on to outline an idea for turning call frames into
PMCs. Leo wasn't sure, pointing out that the call frame would have the same
issues as promoting a continuation. I have to confess that I'd tended to
assume that the PMC that Chip's proposing already exists, and it's called a
continuation.</p>
<p><a href='http://groups.google.com/groups?threadm=20051113034521.GC6553@tytlal.topaz.cx' target='_blank'>groups.google.com</a></p>
<a name=':outer(&quot;foo&quot;) is working'></a><h2><code>:outer(&quot;foo&quot;)</code> is working</h2>
<p>Leo announced that <code>:outer(&quot;foo&quot;)</code> now works, with a couple of caveats.</p>
<p><a href='http://groups.google.com/groups?threadm=437734FF.40203@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Meanwhile, in perl6-language'></a><h1>Meanwhile, in perl6-language</h1>
<a name='Ways to add behaviour'></a><h2>Ways to add behaviour</h2>
<p>The problem with summarizing an ongoing thread that you've not really been
following is getting the context again. I have to confess that, when I returned
to the 'Ways to add behaviour' thread this week I was somewhat stumped. Thomas
Sandlass and Larry appeared to be having fun with terminology and type
algebra. I'm sure that we'll end up with a more robust language as a result of
all this, but it doesn't mean I could follow the discussion as it was
happening.</p>
<p><a href='http://groups.google.com/groups?threadm=20051026173441.GB29341@wall.org' target='_blank'>groups.google.com</a></p>
<a name='$_ defaulting for mutating ops'></a><h2><code>$_</code> defaulting for mutating ops</h2>
<p>Remember last time? Juerd had proposed that mutating ops like <code>++</code> default to
mutating <code>$_</code> in the absence of a left hand argument. It seems that the
discussion convinced Juerd that it wasn't a good idea after all. But, this
being perl6-language, it also seemed to convince others that it is a good idea.</p>
<p><a href='http://groups.google.com/groups?threadm=Pine.LNX.4.33.0510280955200.28049-100000@sharkey.morinda.com' target='_blank'>groups.google.com</a></p>
<a name='Role method conflicts and disambiguation'></a><h2>Role method conflicts and disambiguation</h2>
<p>Discussion of how to handle conflicting role methods and their disambiguation
continued. Unless I'm going soft in the head, I could have sworn that the
original Smalltalk 'Traits' paper (they're called Roles in Perl 6 because we
already have Traits) dealt with disambiguation in a fairly straightforward
fashion. I continue to be reminded of the same joke as last week.</p>
<p><a href='http://groups.google.com/groups?threadm=20051101091913.GB4058@woobling.org' target='_blank'>groups.google.com</a></p>
<a name='Co/contra variance of roles/factories in theory.pod'></a><h2>Co/contra variance of roles/factories in theory.pod</h2>
<p>Err... I haven't the faintest idea what Luke and Thomas Sandlass are talking
about here. Luckily, it seems that Larry did understand it.</p>
<p><a href='http://groups.google.com/groups?threadm=436A5291.7010205@orthogon.com' target='_blank'>groups.google.com</a></p>
<a name='Perl 6 perlplexities'></a><h2>Perl 6 perlplexities</h2>
<p>Michele Dondi worries that the increase in complexity of some aspects of Perl 6
is much bigger than the increase in functionality that the complexity buys
us. In particular Michele is concerned that the Perl 6 parameter passing and
signature stuff is going to be a big loss. People mostly disagreed with
him. Rob Kinyon made a remark that chimed strongly with me, pointing out that
Ruby's OO system is substantially more complex than Perl 5's, but that it's
also a great deal easier to use. (Rob's not alone in this, I am writing most of
my new OO code in Ruby. I fully expect to switch back to Perl 6 as soon as it
becomes good enough though).</p>
<p>Lots of good discussion here. I was convinced once again that Perl 6's
signatures are going to be the best thing since sliced bread. Even if I do
still like Smalltalk method selectors best of all.</p>
<p><a href='http://groups.google.com/groups?threadm=Pine.LNX.4.62.0510211140010.21523@spock.pcteor1.mi.infn.it' target='_blank'>groups.google.com</a></p>
<a name='Implicitly doing a role'></a><h2>Implicitly doing a role</h2>
<p>If a tree falls in a forest with no one to hear it, does it make a sound? If a
class implements the same interface as a role without saying that it does, does
it still do the role? One of these philosophical questions was asked by Austin
Frank. The other is a timeless wossname. Can you guess which is which?</p>
<p>Rob Kinyon thought that the answer to the second question was 'no'. So did
chromatic, citing the usual Dog/Tree problem with 'bark'. After further
thought, chromatic proposed that a class *should* create an implicit empty role
of the same name to make things easy for people writing mock objects and other
entertainingly different variants of the original class.</p>
<p>Decorated Dog anyone?</p>
<p><a href='http://groups.google.com/groups?threadm=436BA54F.9040501@gmail.com' target='_blank'>groups.google.com</a></p>
<a name='The new class sigil'></a><h2>The new class sigil</h2>
<p>Remember when the new class sigil was going to be ¢? Well, we're still getting
one, but it's called ^ now. I think.</p>
<p><a href='http://groups.google.com/groups?threadm=436BB303.4080502@orthogon.com' target='_blank'>groups.google.com</a></p>
<a name='Private methods and role composition'></a><h2>Private methods and role composition</h2>
<p>Jonathan Lang wondered if there was a way of declaring a method as private to a
role, and a role could reclassify a composed method as private. Larry answered
'yes' to the first question and 'no' to the second.</p>
<p><a href='http://groups.google.com/groups?threadm=ef30550b0511051135q5fe874c7t5c2027b2e5a9c7f3@mail.gmail.com' target='_blank'>groups.google.com</a></p>
<a name='=&gt;'s container and binding semantics'></a><h2><code>=&gt;</code>'s container and binding semantics</h2>
<p>Ingo Blechschmidt had some questions about modifying pair keys and values and
about the semantics of binding to a pair value. Larry had answers. And
interesting implicit questions.</p>
<p><a href='http://groups.google.com/groups?threadm=dkl2t3$19o$1@sea.gmane.org' target='_blank'>groups.google.com</a></p>
<a name='Default values for instance variables'></a><h2>Default values for instance variables</h2>
<p>Gaal Yahas thinks it'd be nice to supply default values to instance variables
at declaration time. Luke pointed out that it is actually legal to do just that
in Perl 6, but that pugs doesn't yet implement it.</p>
<p><a href='http://groups.google.com/groups?threadm=20051108160826.GD15437@debian' target='_blank'>groups.google.com</a></p>
<a name='Proposal: rename 'subtype' declarator to 'set''></a><h2>Proposal: rename 'subtype' declarator to 'set'</h2>
<p>Undeterred by the fact that the OED has eight distinct headword entries for
'set', covering four different parts of speech and a prefix form, Thomas
Sandlass proposed changing the <code>subtype</code> declarator to <code>set</code>. Larry agreed
that it might be a way forward, but worried about interference between the
declarative form and the verb 'to set'. Stuart Cook thought that 'subset' might
be slightly less confusing, but Eric the Surnameless thought that that would be
more confusing.</p>
<p><a href='http://groups.google.com/groups?threadm=4371EF61.10107@orthogon.com' target='_blank'>groups.google.com</a></p>
<a name='Test case: Complex numbers'></a><h2>Test case: Complex numbers</h2>
<p>Jonathan Lang posted a skeleton implementation of complex numbers and their
associated arithmetic to the list as a possible test case of various Perl 6
goodies. Luke and Larry both offered comments and suggestions.</p>
<p><a href='http://groups.google.com/groups?threadm=ef30550b0511091821r27f61704m852f3b1d5d31dcf1@mail.gmail.com' target='_blank'>groups.google.com</a></p>
<a name='Given too little'></a><h2>Given too little</h2>
<p>Gaal Yahas seems to have found a possible bug in pugs when using <code>when</code> with an
expression that returns a boolean. It turns out that this might be a bug in the
spec. Getting the semantics of <code>~~</code> nailed down so that <code>when</code> always does the
Right Thing is Hard. Larry's working on it. One fix seems to be to shove the
conditional code into a block. The block is then evaluated (possibly with the
$_ as an argument) and <code>~~</code> returns true if the block returns true.</p>
<p><a href='http://groups.google.com/groups?threadm=20051110083149.GJ15437@debian' target='_blank'>groups.google.com</a></p>
<a name='What's the latest on Iterators'></a><h2>What's the latest on Iterators</h2>
<p>Joe Gottman is worried that the various synopses make plenty of references to
Iterators, but that Iterators aren't actually defined anywhere. He asked for
clarification. Larry supplied some, and, after some prompting from Stéphane
Payrard declared that Perl 6's would do lazy evaluation by default, would
guarantee some kind left to right evaluation, and that, if all else failed the
<code>**</code> steamroller would make things eager again.</p>
<p><a href='http://groups.google.com/groups?threadm=000901c5e6c5$cbce7c20$841d4447@JoeGottman1' target='_blank'>groups.google.com</a></p>
<a name='Acknowledgements, apologies and everything else'></a><h1>Acknowledgements, apologies and everything else</h1>
<p>Matt Fowles was on holiday last week, and didn't have time to write a
summary. Hopefully he was having a fabulous time instead. We hope to be back on
a weekly schedule from next week.</p>
<p>Thanks to the people who contacted me last week. I am still looking for work,
but I also have some leads to follow up on, which is a start. The summaries are
still looking for a sponsor though; if you're interested drop me or Matt a
line, we'd be delighted to hear from you.</p>
<a name='Help Chip'></a><h2>Help Chip</h2>
<p><a href='http://geeksunite.org/' target='_blank'>geeksunite.org</a> -- Chip still needs help.</p>
<a name='The usual coda'></a><h2>The usual coda</h2>
<p>If you find these summaries useful or enjoyable, please consider
contributing to the Perl Foundation to help support the development of
Perl.</p>
<p><a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> -- The Perl Foundation</p>
<p><a href='http://dev.perl.org/perl6/' target='_blank'>dev.perl.org</a> -- Perl 6 Development site</p>
<p>Check out my website, it's lovely.</p>
<p><a href='http://www.bofh.org.uk/' target='_blank'>www.bofh.org.uk</a></p>
<p>Vaguely pretty photos by me can be found at:</p>
<p><a href='http://www.flickr.com/photos/pdcawley' target='_blank'>www.flickr.com</a></p>
</div>
